Data traffic in mobile telecommunications networks is continually increasing. Consequently, operators are employing heterogeneous access networks that utilise multiple radio access technologies (RATs) in order to provide greater capacity, particularly in high traffic areas and areas that otherwise have poor network coverage.
Typically, the radio access technologies utilised as part of these heterogeneous access networks include UMTS Radio Access Network (UTRAN) and an Evolved UTRAN (eUTRAN), and Wi-Fi/WLAN. For example, FIG. 1 illustrates schematically a heterogeneous access network comprised of a UTRAN, an eUTRAN, and a Wi-Fi RAN/WLAN. In this regard, both the UTRAN and eUTRAN standards are defined by the 3rd Generation Partnership Project (3GPP), and the relevant 3GPP standards therefore define capabilities for handling load sharing between these 3GPP RANs. In contrast, the Wi-Fi/WLAN standards are defined by the Institute of Electrical and Electronics Engineers (IEEE), and neither the IEEE standards nor the 3GPP standards define capabilities for handling load sharing between Wi-Fi/WLAN and the 3GPP RANs.
In particular, for most currently available devices (i.e. user equipments (UE), stations (STA) etc) when the device is within the coverage of both a Wi-Fi RAN/WLAN and a 3GPP RAN, the device will automatically attempt to connect to the Wi-Fi RAN/WLAN and will detach from the 3GPP RAN. Therefore, the decision to move from the 3GPP RAN to the WLAN is made without having considered the load and/or performance of either RAN, and can result in a reduction in performance that is detrimental to both the networks and the user.
In order to provide at least some form of load steering between a Wi-Fi RAN/WLAN and a 3GPP RAN, it is currently being proposed that a simple defer mechanism is implemented within the Wi-Fi RAN/WLAN. According to such a defer mechanism, when a device attempts to associate with the Wi-Fi RAN/WLAN, any relevant conditions are evaluated and it is thereby determined whether the device should use the Wi-Fi RAN/WLAN or an available 3GPP RAN. The Wi-Fi RAN/WLAN can then accept or reject the attempt to associate with the Wi-Fi RAN/WLAN in accordance with this determination, thereby steering the device to either the Wi-Fi RAN/WLAN or the 3GPP RAN.
Ideally, the conditions evaluated by the Wi-Fi RAN/WLAN will include any of current and/or predicted load and/or performance of both the Wi-Fi RAN/WLAN and the 3GPP RAN, and the current and/or predicted performance of the device (e.g. the radio link between the device and the RAN). However, in order to be able to obtain load and/or performance information from the 3GPP RAN, the Wi-Fi RAN/WLAN needs to be able to identify the device in the 3GPP RAN using a permanent 3GPP identifier that is associated with the device, such as the International Mobile Subscriber Identity (IMSI).
Whilst the a 3GPP identifier such as the IMSI associated with the device can be obtained if the device is authenticated to the Wi-Fi RAN using either the Extensible Authentication Protocol Method for GSM Subscriber Identity Module (EAP-SIM) or the Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA), this authentication is a network layer (Layer 3) process that will typically be initiated after the establishment of a data link layer (Layer 2) connection between the device and an Access Point (AP) of the Wi-Fi RAN/WLAN. Consequently, the Wi-Fi RAN/WLAN cannot obtain the IMSI until relatively late in the attachment process, which can therefore cause problems if the device is subsequently deferred away from the Wi-Fi RAN/WLAN. For example, FIG. 2 is a signalling flow diagram that illustrates the conventional procedures implemented when a device associated with a WLAN.
In particular, as it is often the case that a device will temporarily lose connectivity with a Wi-Fi RAN/WLAN, most devices will be configured to attempt to re-attach to a WLAN AP. Therefore, if a data link layer connection has already been established, such that the device has already been provided with an IP address before the deferral decision is made, then this will often result in the device attempting to re-attach to the WLAN AP after a deferral, thereby preventing the device from being steered towards the 3GPP RAN.